Amazon CloudWatch Observability アドオンを利用して SageMaker HyperPod を監視してみた
こんにちは!クラウド事業本部コンサルティング部のたかくに(@takakuni_)です。
SageMaker HyperPod はいくつかオブザバビリティツールと統合しており、 CPU/GPU 使用率をはじめとした監視機能をシームレスに利用できます。
今回は Amazon CloudWatch Observability アドオンを利用して SageMaker HyperPod の監視してみたいと思います。
CloudWatch Observability アドオン
CloudWatch Observability アドオンは EKS ノードのメトリクス監視ツールです。
アドオンをインストールすることで、Fluent Bit, CloudWatch Agent をクラスター内にセットでインストールできます。
CloudWatch Observability アドオンは Container Insights とも統合しており、強化されたオブザバビリティメトリクスにより、 NVIDIA, AWS Traininum などの GPU 、EFA など HPC 領域のメトリクスも収集できるポイントが強みです。
また、SageMaker HyperPod のノード用にアラートに利用できそうなメトリクスもいくつか用意されています。詳しいメトリクスの内容は以下をご覧ください。
やってみる
今回は CloudWatch Observability アドオンを SageMaker HyperPod クラスター用の EKS クラスターにインストールしどのようなメトリクスが監視できるのか、ダッシュボードを眺めてみたいと思います。
IAM ポリシーのアタッチ
EKS アドオンをインストールする前に CloudWatchAgentServerPolicy をインスタンスグループの IAM ロールにアタッチします。
通常の EKS の場合、 IRSA を利用する方法またはワーカーノードの IAM ロールに CloudWatchAgentServerPolicy をアタッチする方法のどちらかを選択できますが、 SageMaker HyperPod の場合は IAM ロールに CloudWatchAgentServerPolicy をアタッチする方法になります。
Attach the CloudWatchAgentServerPolicy IAM policy to your worker nodes. To do so, enter the following command. Replace my-worker-node-role with the IAM role used by your Kubernetes worker nodes.
私は Terraform でやったのですが、以下のようになりました。
###################################################
# IAM Role for SageMaker HyperPod Cluster
###################################################
resource "aws_iam_role" "hyperpod" {
name = "${local.prefix}-hyperpod-role"
assume_role_policy = jsonencode({
Version = "2012-10-17",
Statement = [
{
Effect = "Allow",
Principal = {
Service = "sagemaker.amazonaws.com"
},
Action = "sts:AssumeRole"
}
]
})
}
resource "aws_iam_role_policy_attachment" "hyperpod_managed" {
role = aws_iam_role.hyperpod.name
policy_arn = "arn:aws:iam::aws:policy/AmazonSageMakerClusterInstanceRolePolicy"
}
resource "aws_iam_role_policy_attachment" "hyperpod_observability" {
role = aws_iam_role.hyperpod.name
policy_arn = "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy"
}
data "aws_iam_policy_document" "hyperpod_vpc" {
statement {
effect = "Allow"
actions = [
"ec2:AssignPrivateIpAddresses",
"ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:DeleteNetworkInterface",
"ec2:DeleteNetworkInterfacePermission",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",
"ec2:DetachNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:UnassignPrivateIpAddresses",
"ecr:BatchGetImage",
"ecr:GetAuthorizationToken",
"ecr:GetDownloadUrlForLayer",
"eks-auth:AssumeRoleForPodIdentity"
]
resources = ["*"]
}
statement {
effect = "Allow"
actions = [
"ec2:CreateTags",
]
resources = ["arn:aws:ec2:*:*:network-interface/*"]
}
}
resource "aws_iam_policy" "hyperpod_vpc" {
name = "${local.prefix}-vpc-policy"
description = "IAM policy for SageMaker HyperPod VPC"
policy = data.aws_iam_policy_document.hyperpod_vpc.json
}
アドオンのインストール
それでは、アドオンをインストールしましょう、 IAM ポリシーがセットアップできていれば他に気にすることはないです。とてもシンプルで良いですよね。
aws eks create-addon --cluster-name cluster-name
--addon-name amazon-cloudwatch-observability
--configuration-values "configuration json"
configuration json
は以下を設定しました。
{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"kubernetes": {
"kueue_container_insights": true,
"enhanced_container_insights": true
},
"application_signals": {}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}
}
}
Terraform だと次のようになります。
resource "aws_eks_addon" "amazon_cloudwatch_observability" {
cluster_name = aws_eks_cluster.this.name
addon_name = "amazon-cloudwatch-observability"
resolve_conflicts_on_create = "OVERWRITE"
configuration_values = jsonencode({
agent = {
config = {
logs = {
metrics_collected = {
kubernetes = {
kueue_container_insights = true
enhanced_container_insights = true
}
application_signals = {}
}
}
traces = {
traces_collected = {
application_signals = {}
}
}
}
}
})
depends_on = [
awscc_sagemaker_cluster.this,
]
}
負荷掛け
GPU はお高いので、今回 worker-group には m5.2xlarge(8vCPU, 32 GB メモリ)の CPU インスタンスを 2 台使用しました。stress コマンドで負荷がけしてみました。
apiVersion: apps/v1
kind: Deployment
metadata:
name: cpu-memory-stress-deployment
labels:
app: cpu-memory-stress
spec:
replicas: 2 # Podのレプリカ数を1に設定
selector:
matchLabels:
app: cpu-memory-stress
template:
metadata:
labels:
app: cpu-memory-stress
spec:
containers:
- name: cpu-memory-stress-container
image: polinux/stress # stressツールを含む軽量なイメージ
command: ['stress'] # 実行するコマンドを明示的に指定
args:
- '--cpu'
- '4' # 4つのスレッドでCPUを負荷
- '--vm'
- '7' # 7つのスレッドでメモリを負荷
- '--vm-bytes'
- '4G' # 各スレッドが4 GiBのメモリを確保(合計28 GiB)
- '--timeout'
- '600s' # 600秒間(10分間)負荷をかける
resources:
requests:
cpu: '4' # 最低限必要なCPUリソース(4 vCPU)
memory: '28Gi' # メモリリクエスト
limits:
cpu: '4' # 最大4 vCPUを使用
memory: '28Gi' # メモリ制限
ダッシュボードを確認する
1 時間ほど立ち上げたため、ダッシュボードを確認してきます。
HyperPod
HyperPod クラスターを開くと一発目にダッシュボードとして使用率が可視化できるようになっていました。また、インスタンスグループ別に GPU/CPU 数、利用率をフィルタリングできそうです。
後日ブログにしますが HyperPod タスクガバナンスとも統合しており、チームごとにコンピュートの利用率を見られるようになるみたいです。
新しい Amazon SageMaker HyperPod タスクガバナンスを使用して、モデル開発のためにアクセラレーターの使用率を最大化より引用
私の場合、タスクガバナンスは利用していなかったため、インストール画面のみとなっていました。
Container Insights
右上に「コンテナインサイトでの監視」とクリックできるボタンがあったため踏んでみます。
Container Insights に遷移するとクラスターや名前空間別にメトリクスを可視化できるようになっています。
また、赤枠の部分は HyperPod ならではの部分ですね。
左下の HyperPod ノードのみは EKS クラスターに複数ノードが相乗りしている時に使えそうです。
HyperPod ノードのステータスの info ボタンをクリックするとメトリクスの名前が出てきました。ラベルによってメトリクス出すのおもしろいですね。
自動ノード復旧は発生するものの、 hyperpod_node_health_status_unschedulable
や hyperpod_node_health_status_unschedulable_pending_replacement
などは監視項目にしてもいいかもしれません。
まとめ
以上、さらっとですが「Amazon CloudWatch Observability アドオンを利用して SageMaker HyperPod の監視してみた」でした。
今回は見られなかったですが、Container Insights が拡張されたことによる GPU 利用率の監視はかなりみたい部分にフォーカスできていて良い機能なのではないかと思いました。
セットアップも非常にシンプルですぐに導入できそうな印象を受けました。
このブログがどなたかの参考になれば幸いです。クラウド事業本部コンサルティング部のたかくに(@takakuni_)でした!